feat(web): acknowledged shared tx publishing - #3727

Codecov Report

❌ Patch coverage is 94.02348% with 56 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

@@            Coverage Diff             @@
##             main    #3727      +/-   ##
==========================================
+ Coverage   77.83%   77.89%   +0.05%     
==========================================
  Files        1329     1333       +4     
  Lines      126868   127430     +562     
  Branches    11035    11092      +57     
==========================================
+ Hits        98746    99257     +511     
- Misses      24968    25015      +47     
- Partials     3154     3158       +4     

Flags with carried forward coverage won't be shown. Click here to find out more.

... and 3 files with indirect coverage changes

Greptile Summary

This change adds acknowledged browser publishing to shared robot transmit channels, with relay correlation and SDK receipt handling. Two command-delivery reliability problems were reproduced: web/sdk/src/session.ts can accept a publish after its control stream has ended and delay failure until the local timeout, while dimos/web/relay_bridge/relay_bridge_module.py can report a publish failure after the command was already delivered. These paths should be corrected before merging.

Confidence Score: 3/5

Not safe to merge until disconnect-state handling and post-delivery acknowledgement semantics are corrected.

Focused executable checks reproduced both independent command-delivery failures with captured source and runtime output. The SDK check exercised the real session and transport lifecycle; the bridge check exercised the checked-out frame handler with both healthy and raising subscriber paths.

Files Needing Attention: web/sdk/src/session.ts needs to invalidate publish eligibility when its control stream ends. dimos/web/relay_bridge/relay_bridge_module.py needs to avoid returning a definite rejection after broadcast has occurred.

_{Reviews (1): Last reviewed commit: "feat(web): acknowledged shared tx publis..." | Re-trigger Greptile}

Adds shared input channels so multiple browser clients can send messages to a robot. Developers declare these channels in the cockpit configuration. The bridge converts incoming JSON into typed messages for modules.

Isn't this a safety risk? There should always be one clear owner of hardware such that the robot should not have conflicting instructions.

Adds shared input channels so multiple browser clients can send messages to a robot. Developers declare these channels in the cockpit configuration. The bridge converts incoming JSON into typed messages for modules.

Isn't this a safety risk? There should always be one clear owner of hardware such that the robot should not have conflicting instructions.

This is already the case. The relay enforces one client controlling the robot at a time (it has to arm by sending teleop_start and wait to receive teleop_started).

This PR lets you declare other channels onto which different clients can send. This is not intended for teleoping, but for other reasons where two clients would need to send messages simultaneously. This is the case for the chat for example. If you have two clients viewing the same robot, they should both be able to interact with chat. You shouldn't have to "arm" chat to type something in chat.

Note that "shared" is not the default. You have to opt into it and someone should be careful to not use it to send cmd_vel commands.